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Background:  The  U.S.  Air  Force  has  sponsored  a  number 
of  SB  Independent  Technical  Assessments  (ITAs)  on 
acqutsition  programs  that  operated  between  2006  and 
2009.  The  programs  focused  on  the  development  of  IT 
systems,  communications,  command  and  control, 
avionics,  and  electronic  warfare  systems.  This  blog  post 
Is  the  second  in  a  series  that  Identifies  four  themes  across  acquisition 
programs  that  the  SCI  identified  as  a  result  of  our  ITA  work.  Other  themes 
explored  in  the  senes  Include  misaligned  incentives,  the  evolution  of 
science  projects,  and  common  infrastructure  and  Joint  programs.  This 
post  explores  a  related  second  theme,  the  need  to  sell  the  program, 
which  deschbes  a  situation  in  which  people  Involved  with  acquisition 
programs  have  strong  incentives  to  *seir  those  programs  to  their 
management,  sponsors,  and  other  stakeholders  so  that  they  can  obtain 
funding,  get  them  off  the  ground,  and  keep  them  sold. 
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Happy  Memorial  Day  from  all  of  us  here  at  the  SB.  I'd  like 
to  take  advantage  of  this  special  occasion  to  keep  you 
apprised  of  some  recent  technical  reports  and  notes  from 
the  SB.  It's  part  of  an  ongoing  effort  to  keep  you 
informed  about  the  latest  work  of  SB  technologists. 

These  reports  highlight  the  latest  work  of  SB  technologists  In  embedded 
systems,  cyber  security,  appraisal  requtrements  for  CMMI  Version  1,3. 
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Today’s  Presenter 


Grace  Lewis  is  a  senior  member  of  the  SEI  technicai  staff  within  the  Systems  of  Systems  Practice 
(SoSP)  Initiative  in  the  Research,  Technoiogy,  and  Systems  Soiutions  (RTSS)  Program.  Her  current 
interests  and  projects  are  in  service-oriented  architecture  (SOA),  cloud  computing,  context-aware 
appiications,  and  technologies  for  systems  interoperabiiity.  Her  latest  publications  include  multiple 
reports  and  articles  on  these  subjects  and  a  book  in  the  SEI  Software  Engineering  Series  to  be 
pubiished  iater  in  2011 .  She  is  also  a  member  of  the  technical  faculty  for  the  Master  in  Software 
Engineering  Program  at  Carnegie  Mellon  University  (CMU).  Lewis  holds  a  bachelor’s  degree  in 
systems  engineering  and  an  Executive  MBA  from  Icesi  University  in  Cali,  Colombia;  and  a  master’s 
degree  in  software  engineering  from  CMU. 
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Polling  Question  1 


Which  is  the  quaiity  attribute  that  is  most  positively  affected  by  the  use  of 
SOA  concepts  and  technoiogies? 

•Availability 

•Modifiabiiity 

•Interoperabiiity 

•Performance 

•Security 
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Polling  Question  2 


Which  is  the  quaiity  attribute  that  is  most  negativeiy  affected  by  the  use 
of  SOA  concepts  and  technoiogies? 

•Modifiabiiity 

•Performance 

•Reiiabiiity 

•Scalability 

•Security 
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What  is  SOA? 


o 

Service-oriented  architecture  is  a  way  of  designing,  developing, 
deploying  and  managing  systems,  in  which 

•  Services  provide  reusable  business  functionality  via  well-defined  interfaces. 

•  Service  consumers  are  built  using  functionality  from  available  services. 

•  There  is  a  clear  separation  between  service  interface  and  service 
implementation. 

-  Service  interface  is  just  as  important  as  service  implementation. 

•  An  SOA  infrastructure  enables  discovery,  composition,  and  invocation 
of  services. 

•  Protocols  are  predominantly,  but  not  exclusively,  message-based 
document  exchanges. 
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Services 

Services  are  reusable  components  that 
represent  business/operational  tasks. 

•  Customer  lookup 

•  Credit  card  validation 

•  Weather 

•  Hotel  reservation 


I 


LLLL 
LLLL 
LLLL 


SKYLINE  SUITES 


Services  can  be 

•  Globally  distributed  across  organizations 

•  Reconfigured  into  new  business  processes 


Service  interface  definitions  are 
well-defined  artifacts  available  in 
some  form  of  service  registry. 
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SOA  Infrastructure 


Set  of  technologies  that  bind  service  consumers  to  services 

•  Products,  standards  and  protocols  that  support  communication — typically 
message-based  document  exchanges 

-  Web  Services  (WS*:  HTTP,  SOAP,  WSDL;  REST) 

-  Message-oriented  middleware  (i.e.  IBM  Websphere  MQ) 

-  Publish/subscribe  (i.e.  Java  Messaging  Service  —  JMS) 

-CORBA... 


•  Infrastructure  services  available  to  service  providers  and/or  service 
consumers  to  perform  common  tasks  or  satisfy  QoS  requirements  of 
the  environment 

-  Security,  discovery,  data  transformation,  ... 


Software  Engineering  Institute  Carnegie  Mellon 


Review 

June  2011 

©2011  Carnegie  Mellon  University 


12 


Service  Consumers 


Clients  for  the  functionality  provided  by  the  services 

•  End-user  applications 

•  Internal  systems 

•  External  systems 

•  Composite  services 

Consumers  programmatically  bind  to  services. 
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Components  of  a  Service-Oriented  System 
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Benefits  Associated  with  SOA  Adoption 

Cost-Efficiency 

•  Services  provide  functionality  that  can  be  reused  many  times  by 
many  consumers 

•  Services  become  a  single  point  of  maintenance  and  management  for 
common  functionality 

Agility 

•  Via  service  discovery  mechanisms,  developers  can  find  and  take  advantage 
of  existing  services  to  reduce  development  times 

Legacy  Leverage 

•  Separation  of  service  interface  from  service  implementation  provides  true 
platform  independence 

Adaptability 

•  Separation  of  service  interface  from  service  implementation  allows  for 
incremental  deployment  of  services  and  incremental  modernization 
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Software  Architecture 


The  current  literature  on  software  architecture  offers  many  definitions 


The  definition  we  use  is 

A  software  architecture  for  a  system  is  the  structure  or  structures 
of  the  system,  which  comprise  eiements,  their  externaiiy  visibie 
properties,  and  the  reiationships  among  them* 

Why  create  a  software  architecture? 

•  Because  a  system’s  quality  attributes  can  be  predicted  by  studying 
its  architecture 

What  is  a  quality  attribute? 

•  A  property  of  a  system  by  which  its  quaiity  wiii  be  judged  by  some 
stakehoider  or  stakehoiders 

•  Bass,  L.;  Clements,  P.;  &  Kazman,  R.  Software  Architecture  in  Practice,  Second  Edition.  Boston,  MA:  Addison-Wesley,  2003. 
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Sample  Quality  Attributes 


Accessibility 

Dependability 

Nomadicity 

Serviceability 

Accountability 

Deployability 

Operability 

Simplicity 

Adaptability 

Distributability 

Performance 

Stability 

Administrability 

Durability 

Portability 

Survivability 

Affordability 

Evolvability 

Predictability 

Sustainability 

Agility 

Extensibility 

Recoverability 

Tailorability 

Auditability 

Flexibility 

Relevance 

Testability 

Availability 

Installability 

Reliability 

Timeliness 

Credibility 

Interchangeability 

Repeatability 

Understandability 

Compliant 

Interoperability 

Reproducibility 

Usability 

Composability 

Learnability 

Reusability 

Configurability 

Maintainability 

Safety 

What  does 

Customizability 

Manageability 

Scalability 

each  one  of 

Degradability 

Mobility 

Seamlessness 

these  mean? 

Demonstrability 

Modularity 

Security 
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Quality  Attribute  Scenarios 

A  fully-specified  quality  attribute  scenario  consists  of  six  parts 

•  Stimulus:  condition  effecting  the  system 

•  Response:  activity  as  a  result  of  the  stimulus 

•  Source  of  Stimulus:  entity  that  generated  the  stimulus 

•  Environment:  condition  under  which  the  stimulus  occurred 

•  Artifact  stimulated:  artifact  that  was  stimulated 

•  Response  measure:  measure  by  which  the  system’s  response  will 
be  evaluated 

Quality  attribute  scenarios  should  be  as  specific  as  possible 

•  A  good  scenario  makes  very  clear  what  the  stimulus  is  and  what  the  desired 
responses  of  the  system  are,  in  order  to  avoid  ambiguity 
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Example  Availability 


An  unanticipated  externai  message  is  received  by  a  process  during 
normai  operation.  The  process  informs  the  operator  of  the  receipt  of 
the  message  and  the  system  continues  to  operate  with  no  down  time. 


Source: 

External 
to  system 


Stimulus: 

Unanticipated 

message 


Response; 

Environment:  Inform  operator 
Normal  continue  to 

operation  operate 


Artifact 

Process 


Response 

Measure: 

No  down 
time 
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Misconception:  SOA  Provides  the  Complete 
Architecture  for  a  System 

SOA  is  an  architectural  pattern/style/paradigm  and  not  the  architecture 
of  the  system  itself. 

•  An  architectural  pattern  provides  guidance  that  embodies  best  practices. 

-  The  concrete  elements  and  their  interactions  are  the  architecture  of 
the  system. 

•  Any  number  of  systems  can  be  developed  based  on  an  architectural  pattern. 

-  An  architecture  based  on  SOA  inherits  both  the  good  and  the  bad. 

Corollary:  SOA  cannot  be  bought  off-the-shelf. 

•  System  qualities  have  to  be  built  into  the  architecture  of  the  system. 

•  Decisions  have  to  be  made — service  design  and  implementation, 
technologies,  tradeoffs. 
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SOA  is  NOT  a  Specific  Technoiogy 


SOA  is  an  architectural  pattern 

•  Systems  that  implement  the  SOA  architectural  pattern  are  called  service- 
oriented  systems 

Web  Services  is  one  technology  for  SOA  implementation 


r 


I 


SOA 


i 
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-Key- 
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Realization  Aggregation 

_ _ _ y 


REST 
Services 
and  POX 
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Quality  Attributes  in  Service-Oriented  Systems 


The  following  slides  are  examples  of  common  quality  attribute 
scenarios  for  service-oriented  systems,  plus  an  analysis  of  how  the 
SOA  architectural  pattern  affects  those  qualities 


The  legend  to  Indicate  the  effect  is 


Sample  Interoperability  Scenarios 

Scenario  11 

A  new  business  partner  that  uses  platform  ‘X’  is  able  to 
implement  a  service  consumer  module  that  works  with  our 
available  services  in  platform  ‘Y’  in  two  person-days. 

Scenario  \2 

A  transaction  in  a  legacy  system  running  on  platform  ‘X’  is  made 
available  as  a  Web  service  to  an  enterprise  application  that  is  being 
developed  for  platform  ‘Y’  using  Web  services  technology.  The 
wrapping  of  the  legacy  transaction  as  a  service  with  proper  security 
verification,  transaction  management,  and  exception  handling  is  done 
in  10  person-days. 
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Interoperability 

Interoperability  refers  to  the  ability  of  a  collection  of  communicating 

entities  to  share  specific  information  and  operate  on  it  according  to 

agreed-upon  operational  semantics* 

•  Improved  interoperability  is  a  prominent  benefit  of  service-orientation, 
especially  when  web  services  technology  is  considered 

•  Consumers  and  providers  can  easily  use  and  provide  services  implemented 
in  disparate  platforms  and  different  languages 

Web  Services  promote  cross-vendor  and  cross-platform  interoperability 

•  Mature  when  basic  standards  are  used:  WSDL  and  SOAP 

•  Falls  short  when  new  standards  are  in  the  picture  (e.g.,  WS-Security,  WS- 
Transaction) 

WS-I  organization  was  created  to  promote  interoperability  (ws-i.org) 

•  The  goal  of  WS-I  profiles  is  to  provide  clarifications,  refinements, 
interpretations  and  amplifications  in  areas  of  specific  standards  that  are 
subject  to  multiple  interpretations 

•  Brownsword  et  al.  Current  Perspectives  on  Interoperability.  Software  Engineering  Institute.  2004. 

http://www.sei.cmu.edu/reports/04tr009.pdf 
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Sample  Performance  Scenarios 


Scenario  P1 

The  service  provider  can  process  up  to  ‘X’  simuitaneous  requests 
during  normai  operation,  keeping  the  response  time  on  the  server 
iess  than  ‘Y’  seconds. 

Scenario  P2 

The  roundtrip  time  for  a  request  from  a  service  consumer  in  the  iocal 
network  to  service  ‘X’  during  normai  operation  is  iess  than  ‘Y’  seconds. 
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Performance 


■V 


Performance  in  an  SOA  context  usually  relates  to  response  time  or 
throughput  and  in  most  cases  is  negatively  affected 

•  SOA  is  a  distributed  computing  paradigm;  the  network  increases 
response  time 

•  Cross-platform  interoperability  requires  intermediaries  to  do  data  marshalling 
and  handle  communication 

In  Web  Services,  use  of  XML  impacts  performance 

•  Studies  show  that  XML  messages  can  be  10  to  20  times  larger  than 
binary  messages 

•  XML  requires  three  CPU-  and  memory-intensive  activities 

-  Parsing 

-  Validation 

-  Transformation 
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Sample  Availability  Scenarios 

Scenario  A1 


An  improperly  formatted  message  is  received  by  a  system  during  normal 
operation.  The  system  records  the  message  and  continues  to  operate 
normally  without  any  downtime. 

Scenario  A2 


Unscheduled  server  maintenance  is  required  on  server  ‘X.’ 

The  system  remains  operational  in  degraded  mode  for  the  duration 
of  the  maintenance. 
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Sample  Scalability  Scenarios 


Scenario  S1 


Marketing  landed  several  new  high-volume  accounts  that  will  increase 
service  request  volume  by  a  factor  of  10.  During  normal  operation, 
the  service  requests  are  processed  without  affecting  the  current 
quality  of  service. 


Scenario  S2 

Marketing  landed  several  new  high-volume  accounts  that  will  increase 
service  request  volume  by  a  factor  of  10.  During  normal  operation,  the 
service  requests  are  processed  according  to  the  Service-Level 
Agreements  negotiated  with  each  account. 
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Availability  and  Scalability 


SOA  solutions  usually  rely  on  mechanisms  provided  by  the 
execution  platform 

•  Horizontal  scaling:  Add  load-balanced  computer  servers 

•  Vertical  scaling:  Increase  capacity  of  a  computer  server 

•  Service  scope:  Configure  when  a  new  instance  of  a  service  should  be  created 

-  Once  to  serve  all  requests  (best  if  service  implementation  is  reentrant  or  thread-safe) 

-  For  each  new  service  consumer 

-  For  each  new  request 

Another  mechanism  is  to  design  services  to  be  stateless 

•  To  enable  replication 

SLAs  for  external  services  may  define  availability  requirements 
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Sample  Security  Scenarios 


Scenario  1 


An  attack  is  launched  attempting  to  access  confidential  customer  data. 
The  attacker  is  not  able  to  break  the  encryption  used  in  all  the  hops  of 
the  communication  and  where  the  data  is  persisted.  The  system  logs 
the  event  and  notifies  the  system  administrators. 


Scenario  2 

A  request  needs  to  be  sent  to  a  third-party  service  provider,  but  the 
provider’s  identity  cannot  be  validated.  The  system  does  not  make  the 
service  request  and  logs  all  relevant  information.  The  third  party  is 
notified  as  well  as  with  the  system  administrator. 


Software  Engineering  Institute  Carnegie  Mellon 


SOA  and  Quality  Attributes 

June  2011 

©2011  Carnegie  Mellon  University 


31 


Security 


■V 


Some  aspects  of  SOA  solutions  impact  security 

•  Messages  may  be  transmitted  in  text  format  and  contain  sensitive  metadata 

•  If  external  services  are  used 

-  Identity  of  service  providers  should  be  authenticated 

-  Data  should  be  transmitted  and  stored  securely 

•  Data  in  the  service  registry  should  be  reliable 

•  Authorization  of  clients  to  access  services  has  to  be  configured 

Transport  security  is  usually  addressed  at  the  network  level  (e.g.,  SSL) 
There  are  tradeoffs  with  interoperability,  modifiability  and  performance 
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Sample  Reliability  Scenarios 

Scenario  R1 

A  sudden  failure  occurs  in  the  runtime  environment  of  a  service  provider. 
After  recovery,  all  transactions  are  completed  or  rolled 
back  as  appropriate,  such  that  the  system  maintains  uncorrupted, 
persistent  data. 

Scenario  R2 

A  service  becomes  unavailable  during  normal  operation.  The  system 
detects  the  problem  and  restores  the  service  within  two  minutes. 
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Reliability 


Message  reliability 

•  Messages  should  be  delivered  in  order  and  exactly  once 

•  This  is  usually  a  concern  of  the  SOA  execution  platform,  not  the 
service  developer 

•  Available  standards:  WS-Reliability  and  WS-ReliableMessaging 

Service  reliability 

•  Goal  is  for  the  service  to  operate  without  failure  or  to  report  any  failure 

•  Main  issue  is  transaction  management 

-  Complex  because  of  the  distributed,  multi-platform  —  and  potentially 
multi-organizational  —  context 

-  May  require  compensating  transactions 
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Sample  Modifiability  Scenarios 


Scenario  M1 

A  service  provider  changes  the  service  impiementation,  but  the  syntax 
and  the  semantics  of  the  interface  do  not  change.  This  change  does  not 
affect  the  service  consumers. 

Scenario  M2 

A  service  provider  changes  the  interface  of  a  service  that  is  pubiiciy 
availabie.  The  oid  version  of  the  service  is  maintained  for  12  months, 
and  existing  service  consumers  are  not  affected  within  that  period. 
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Modifiability 


Modifiability  is  the  ability  to  make  changes  to  a  system  quickly  and 
cost  effectively 

•  SOA  promotes  loose  coupling  between  service  consumers  and  providers 

-  Services  are  modular  and  self-contained 

-  There  are  few  well-known  dependencies,  therefore  reducing  the  cost  of 
modifying  the  services 

•  Changing  published  interfaces  can  be  a  challenge,  but  SOA  solutions  deal 
with  these  changes  through 

-  Versioning  mechanisms 

-  Flexible  contracts  specified  in  XML 

-  Special  components  in  the  infrastructure,  such  as  the  registry 
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Summary 


Quality  attributes  have  the  strongest  influence  on  architectural 
design  decisions 

•  Quality  attributes  requirements  can  be  captured  as  scenarios 

SOA  is  a  design  pattern  that  promotes  interoperability  and  modifiability, 
usually  at  the  expense  of  performance  and  security 

•  SOA  is  not  a  complete  architecture 

•  It  is  often  combined  with  other  patterns  and  tactics,  e.g. 

-  Brokers  for  data  format  and  protocol  translation 

-  Routers  for  message  routing  based  on  runtime  factors 

-  Asynchronous  queues  for  increased  decoupling  between  consumers 
and  providers 

-  Registries  (metadata  centralization)  for  service  discovery 
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Agenda 


Service-Oriented  Architecture  and  Software  Architecture:  Review 
Service-Orientation  and  Quality  Attributes 

Summary  and  Future  Challenges 
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SOA  Adoption  in  Practice 


What  practice  shows  is  that  SOA  is  currently  the  best  option  avaiiabie 
for  systems  integration  and  leverage  of  legacy  systems 


SOA  has  “crossed  the  chasm,”  according  to  a  recent  Software  AG 
user  survey  in  which  90  percent  of  the  respondents  ciaim  to  have  made 
some  commitment  to  SOA  adoption 

•  Have  moved  from  early  adopter  to  early  majority 

There  is  active  research  and  development  in  many  aspects  related 
to  SOA 

•  Probably  too  many  aspects,  which  is  also  a  problem 

The  bottom  line  is  that  organizations  are  stiii  investing  in  SOA 
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However,  We  Want  More! 


As  SOA  is  adopted  within  organizations  and  becomes  a 
mainstream  paradigm  for  systems  development,  requirements  and 
expectations  increase 


The  loosely-coupled,  stateless,  standards-based  nature  of  the 
relationship  between  service  consumers  and  service  providers  is 
changing  to  meet  these  new  requirements 


Global  enterprises  and  the  emerging  market  of  third-party  services  and 
cloud  computing  are  also  placing  expectations  on  service-oriented 
system  architecture  and  design 

•  As  organizations  expand  their  systems  to  cross  organizational  boundaries, 
the  requirements  on  their  systems  also  expand 
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SOA  Is  Potentially  Being  Stretched  Beyond 
Its  Limits 

What  was  initially  an  approach  for  asynchronous  document-based 
message  exchanges  now  has  performance,  availability,  reliability, 
security,  and  other  expectations  of  traditional  distributed  systems 

The  architect  of  service-oriented  systems  is  going  to  play  a  crucial  role 

•  Determining  what  expectations  can  or  cannot  be  met  by  current 
SOA  technologies 

•  Determining  where  tradeoffs  can  be  made  for  the  accomplishment  of  system 
qualities  without  having  to  sacrifice  the  loosely  coupled,  stateless,  standards- 
based  characteristics  that  have  made  SOA  a  worthwhile  technology 

•  Performing  early,  contextual  technology  evaluation  and  continuous 
technology  scouting 


Need  to  Separate  Service-Orientation  from  SOA 
implementation  Technologies 


The  concept  of  service-orientation  is  here  to  stay,  but  the  technoiogies 
wiil  change  over  time  to  meet  new  requirements 


A  chailenge  for  architects  of  service-oriented  systems  is  to  reduce 
the  impact  of  changing  SOA  technoiogies  from  the  impiementation 
of  service-oriented  concepts 


•  “Separation  of  concerns  on  steroids” 
SOA  is  not  dead! 


Software  Engineering  Institute  Carnegie  Mellon 


Summary  and  Future  Challenges 
June  2011  42 

©2011  Carnegie  Mellon  University 


Contact  Information 


Grace  A.  Lewis 
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SOA  Architect  Professional  Certificate 


Learn  How  to  Architect 
Service-Oriented  Systems 


From  the  Experts  at  the  Software  Engineering  Institute 


Architect  with  confidence. 

The  SEl  prepares  SOA  architects  to  make  ’heir  o'.vn  decisions  3i>3ut  the 
benefits,  potential  risks,  and  pitfalls  of  SOA  adopt  ^n. 

All  courses  are  technology  agnostic. 

Thej  ariply  to  serviee-orlented  sv^-ter*  in  general  and  do  not  favor  any 
specific  implerrtentation  technologies,  'ools,  or  products. 

Ready-to-implement  methods. 

All  courses  In  *he  sequence  oriented  *oward  practitioners  and  designed  to 
provide  skills  that  can  be  ar'plled  on  the  job  right  away. 


I  .'O  SOA  instructors  discuss  three  taker.vr,  s  i ron-  "  e  SOA 
Ctoi'inoaie. 
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